The Object Request Broker (ORB) manages interaction between clients and servers. This includes the distributed computing responsibilities of location, referencing and 'marshaling' of parameters and results.
The CORBA specification defines an architecture of interfaces and services that must be provided by the ORB, no implementation details. These are modular components so different implementations could be used, satisfying the needs of different platforms.
The ORB manages the interactions between clients and object implementations. Clients issue requests and invoke methods of object implementations.
The client side architecture provides clients with interfaces to the ORB and object implementations. In consists of the following interfaces : Dynamic Invocation - This interface allows for the specification of requests at runtime. This is necessary when object interface is not known at run-time. Dynamic Invocation works in conjunction with the interface repository. IDL Stub - This component consists of functions generated by the IDL interface definitions and linked into the program. The functions are a mapping between the client and the ORB implementation. Therefore ORB capabilities can be made available for any client implementation for which there is a language mapping. Functions are called just as if it was a local object. ORB Interface - The ORB interface may be called by either the client or the object implementation. The interface provides functions of the ORB which may be directly accessed by the client (such as retrieving a reference to an object.) or by the object implementations. This interface is mapped to the host programming language. The ORB interface must be supported by any ORB.
ORB core - Underlying mechanism used as the transport level. It provides basic communication of requests to other subcomponents.
The implementation side interface consists of the ORB Interface, ORB core and: IDL Skeleton Interface - The ORB calls method skeletons to invoke the methods that were requested from clients. Object Adapters (OA) - Provide the means by which object implementations access most ORB services. This includes the generation and interpretation of object references, method invocation, security and activation. The object adapter actually exports three different interfaces: a private interface to skeletons, a private interface to the ORB core and a public interface used by implementations. The OA isolates the object implementation from the ORB core. The CORBA specification envisions a variety of adapters, each providing specific services. The Basic Object Adapter (BOA) is the most generic of the Object adapters.
The client request a service from the object implementation. The ORB transports the request which invokes the method using object adapters and the IDL skeleton.
The client has an object reference,an operation name and a set of parameters for the object and activates operations on this object. The Object Management Group / Object Model defines each operation to be associated with a controlling parameter, implemented in CORBA as an object reference. The client does not know the location of the object or any of the implementation details.The request is handled by the ORB, which must locate the target object and route the request to that object. It is also responsible for getting results back to the client.
The request makes use of either the dynamic invocation (dynamic link) or the IDL Stubs (static link) interface. Static links use the IDL stubs IDL stubs (as local function calls) and dynamic request use the DII . The object implementation is not aware of the difference. If the interface was defined in the IDL and the client has an interface for the target object the IDL stub is used. This stub is specific to the target object. The DII is used when the interface is not known at runtime. The DII uses information stored in the interface repository to establish the request. Request are passed from the ORB to the object implementation through the IDL skeleton. The object implementation is made available by using information stored in the implementation repository. The object implementations encapsulate state and behavior of the object. CORBA only defines the mechanisms to invoke operation, it does not define how activated or stopped, made to persist, etc.
Object Adapters (OA) are the primary ORB service providers to object implementations. OA have a public interface which is used by the object implementation and a private interface that is used by the IDL skeleton.
OA's may be specialized. They are a major player in delivery of requests and are the primary service provider for object implementations. CORBA only defines the Basic Object Adapter (BOA) and any CORBA implementation must provide a BOA. CORBA assumes the definition of additional object adapters. There should not be a large number of adapters since one adapter can service more than one implementation.
Request are issued upon object references. Object references are opaque references only uniform within an ORB implementation. Since both clients and servers using objects references as opaque references, different representation will not affect them. CORBA does have an object reference that is used to denote no object. It is guaranteed to be different from any other object reference, and usually maps to the null or nil object.
Object services refer to fundamental services provided by their own objects that support common interactions between other objects. The services follow the OMG Common Object Services Specification (COSS) guidelines. Current object services include:
This is one of the newer areas of OMG standardization. These are higher level specification for supporting interoperability. This is the level most application developers will utilize. The specifications call for higher-level services and vertical market specialty areas. Some examples of common facilities would include system management and compound documents. Specialty areas would be more specialized such as geospatial data processing and financial services.
The ORB provide operations on references and strings. Two operations for converting an object reference to strings and back again. An is_nil operation for testing whether an object reference is referencing no object. A duplicate operation allows for a duplicate reference to the same object to be created. A release operation is provided to reclaim the memory used by an object reference.
In addition, the ORB provides two operations used for returning meta-information from the interface and implementation repositories. The 'get_interface operation is used to extract information regarding the object type. The get_implementation operation returns an object that describes the object implementation from the Implementation Repository.
©1998, Sage Technologies